【レポート】「Media-JAWS 【第4回】8/23。あの日までのボクと、あの日からのボク　～AWSは止まらない～」#jawsug #mediajaws

11/20に行われた第四回Media-JAWSに参加しましたので、その参加レポートになります。

#レポート

大前諒祐

2019.11.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大前です。

2019/11/20 に開催された「Media-JAWS 【第4回】8/23。あの日までのボクと、あの日からのボク　～AWSは止まらない～」に参加してきましたので、レポートを書いていきます。

Media-JAWS 【第4回】8/23。あの日までのボクと、あの日からのボク　～AWSは止まらない～

レポート

イベント概要

8/23 AWS障害発生したあの日に何してたか。どう感じたか。どう対応したか。今後どう対応するか。考えがどう変わったか。技術的なものでも思考的なものでも、自分のことでも周りの人のことでも、あの日を堺に変わったこと、変わってないこと、色々共有しあいましょう。また、定番の事例紹介も実施予定。両テーマとも登壇者募集中ですので、ぜひご応募ください。「こういうことを話したい、話してもよいか」みたいなご相談も受付中ですので、ご気軽にご相談ください！ ※スケジュールは当日までに変更になる可能性があります。ご了承ください。

会場は合同会社 DMM.com 様のオフィスで、初めてお邪魔したのですがすごく綺麗な会場で素敵でした！

タイムテーブル

Timeline	Title	Speaker
19:00 - 19:30	Registration & Social
19:30 - 19:35	イベント説明
19:35 - 19:50	会場スポンサー様事業紹介	合同会社DMM.comさま
19:50 - 20:00	LT 1	株式会社IMAGICA Lab. 蜂須賀さま
20:00 - 20:10	LT 2	株式会社日本経済新聞社高安さま
20:10 - 20:20	休憩
20:20 - 20:30	LT 3	株式会社テレビ東京段野さま
20:30 - 20:45	事例紹介 1	株式会社Ｊストリーム千葉さま
20:45 - 21:00	事例紹介 2	北海道テレビ株式会社三浦さま
21:00 - 22:00	懇親会	イベント会場にて引き続き行います。ぜひご参加ください

会場スポンサー様事例紹介合同会社DMM.comさま

東京大学様と共同でリアルタイム音声変換技術の研究をされているとの事で、簡単な技術の解説と実際にイベント案件を行った際のお話でした。

リアルタイム音声変換技術とは
- 分析 → 学習・変換 → 生成の流れ
- GAN（敵対的生成ネットワーク）を採用している
  - 人の声を真似るシステムと見破るシステムを作成する
- 声の高さ、声色、かすれ具合を分析
- 機械学習で学習・変換
- 声の高さ、声色、かすれ具合をそれぞれ変換して出力
想定用途
- ボイスアクターの声をモデル化
  - 代理役者の実現
  - 自身の声の保存
  - 多言語吹替え
- 変成器
  - 理想のキャラクターボイスの実現
  - 声質の匿名化
今後のロードマップ
- まずはリアルタイム音声変換ができた
  - まだイベントレベル用途
- 高品質モデル作成に向けた知見の獲得やアルゴリズム改善を通して
- 低遅延化、非リアルタイム高音質化、モバイル対応など突き詰めて
- より良いシステムを目指す
実例
- 日テレ様から案件を頂いた
- 期日がタイト
- 声優さんの収録、生音声データ！
- でもモデル作っても全然うまくいかない
- 試行錯誤の日々
- 作ったもの
  - お客様にアテレコを体験してもらうシステム
  - 音声変換には時間がかかるため、アテレコ担当者に見せる映像のタイミングを工夫したりした
- イベントの結果
  - プレス記事大量インプレッション！
  - 来場者も2500人超え
今回のイベントを通して
- 高品質モデル作成知見やアルゴリズムの改善が出来た
- ロードマップに沿って進めていきたい

LT1 株式会社IMAGICA Lab. 蜂須賀さま

登壇者の蜂須賀様は「映像業界の働き方を変えたい」をミッションに活動されている方で、今回は障害あった 8/23 についてのお話でした。

AWS の利用状況
- 60 アカウント以上保有
- 親アカウントに紐づけて管理
- ログ管理したり DX 用のアカウントがあったり
- ベストプラクティスに沿ったアカウント管理
障害当日
- スクラム合宿で会社にいなかった
- 来たる 13:37
  - 障害内容を見て、対象の AZ を外せば良いと思った
  - 外したけどヘルスチェックが終わらない・・
    - 他メンバーに聞いたら終わってたり終わってなかったりする
    - 正常だと思っていたサービスでも 404 だったり 500 だったり
  - お客様に連絡
    - お客様も当然障害を認識していた
    - 全体的に「しょうがない」「どうしようもなかった」という風潮だったそう
対策
- マルチリージョン、マルチクラウドなら良いとの噂もあるが
- そこまでやるサービスなのか決めることが大切
- SLAを定義しよう
結論
- 止まるのは仕方ない、SLAを握っておく

LT2 株式会社日本経済新聞社高安さま

登壇者の高安様は日経電子版の開発に従事しているそうで、自社サービスに対する障害の影響をお話されていました。

障害の日経電子版への影響
- RDS が障害で停止
- 記事を格納する DB だったので新規の記事がサービスに反映出来なくなった
  - 3時間以上
  - ニュースメディアとしては致命的
- 幸い既存記事の参照は問題なかった
- 復旧が長引いた理由
  - Single AZ 構成だった
  - フェイルオーバーする想定だったがうまくいかない・・・
  - ドキュメントを参照した構成だったが、AWS でも想定し得ないパターンだったらしく、ドキュメント通り動かない
  - 障害後にドキュメントが改定された
振り返り
- 昼だったからすぐに気づけた
  - 夜でも通知がくる様に監視を行なっているが、昼よりは遅れていたはず
- 通知メールの宛先の見直し
- 障害が原因で障害のお知らせ自体ユーザーにお知らせ出来なかった
  - 別の手段を確保しておく必要性を認識
- 日経グループで情報共有を行なった
今後
- 普段から障害に対する訓練をしておかないといざというときに対応できない
  - とはいえあらゆるケースを想定して準備するのは大変
- 少なくとも一度発生したことに対する対策はちゃんとする
  - 仕組みを帰る
  - 対応できる様な準備を
- クラウド移行が遅れてしまうのではと懸念
  - 意外と AWS が落ちたならしょうがないよね的な風潮があった
- マルチクラウドはハードルが高い
  - 一部 Google サービスの使用を検討

LT3 株式会社テレビ東京段野さま

登壇者の段野様による、自社サービスへの障害の影響と合わせて社内の取り組みなどを紹介頂きました。

障害の影響
- ほぼ影響なかった
  - 一部サービスだけ
  - ユーザーにはほぼ影響なかった
  - サーバレス構成のシステムを運用していた
障害1ヶ月前に社内情報システムの3原則を策定していた
- クラウド・バイ・デフォルト
- パッケージ・ファースト
- 社内オープンデータ
- そんな最中障害発生
  - 自然災害の様な認識
社内的にはクラウドへの意識転換がまだ出来ていない認識
- 東京の会社でもまだまだクラウド・バイ・デフォルト出来ていない印象がある
- 放送とインターネットの世界は違う
  - 放送
    - ミッションクリティカル
    - インフラからアプリまで自前
    - リスクを最小限に抑えるための取り組みが基本
  - インターネット
    - 粘り強いが壊れやすい
    - クラウド基盤
    - SLAも放送より低い
- 放送業界エンジニアに対するクラウドについての正しい理解の浸透が必要
社内取り組み
- 例としてAWS Summitのセッションが紹介されました
  - 【レポート】ナショナルオーストラリア銀行事例：いかにして1年間で3,000人のAWSエンジニア育成に成功したのか #AWSSummit
- 社内 AWS 勉強会を実施
  - 学び・触り・理解する
- 資格取得の推奨と補助
- EDGEクラブの実施
  - 業務時間を使って新しいことに取り組む
  - 学びたいことに対するアウトプットとインプットの繰り返し

事例紹介１株式会社Jストリーム千葉さま

登壇者の千葉様は放送局様向けの動画配信案件に多く携わっており、今回は AWS Elemental MediaTailor に関連した動画広告配信のお話でした。

MediaTailor を使ったきっかけ
- もともと Adobe Prime Time で SSAI 実現していたが移行することに
- MediaTailor 渡された
- 当時の知識
  - なんとなく SSAI
  - エンコードそこまで知らない
  - AWS 全く知らない
  - Elemental 全く知らない
- とりあえず検証してみたら使えそうだった
広告動画配信の基礎
- インストリーム広告とアウトストリーム広告
  - 動画の再生中に配信されるものがインストリーム
  - MediaTailorはインストリーム
- プレロール、ミッドロール、ポストロール
  - 広告が挿入される位置の違い
  - MediaTailorはプレロールとミッドロール
- 広告の種類
  - VAST
    - XML 形式、広告のテンプレート
    - 広告素材の取得先、視聴ビーコンの送信先等が定義される
  - AdPods
    - 広告動画を段積みで配信する仕組み
    - 一つのCM枠に対して複数の広告を差し込むための技術
- 方法
  - CSAI と SSAI
  - CSAI
    - クライアントサイドで広告を配信する仕組み
    - プレイヤーが本編と広告動画を出し分ける
    - プレイヤー改修が大変
    - 本編と広告の切り替え時にロードが発生
    - プレイヤーから広告視聴ビーコンを送信するので正確に取得
  - SSAI
    - サーバサイドで広告を配信する仕組み
    - MediaTailor はこっち
    - 広告挿入サーバーがある
    - プレイヤー改修不要
    - 切り替えロードない
    - ログの取得は CSAI に比べると正確に出来ない
MediaTailor とは
- プレロールとミッドロールが SSAI で挿入可能
- 配信用 URL の生成
- 広告動画のトランスコード
事例
- 実際に Live 動画配信に広告を挿入した事例をいくつか紹介頂きました
  - VANC インサータを使用したマスター機器と連動した広告挿入
  - プレイヤーを作り込み、SSAI で CSAI 同等のログ取得を実現
まとめ
- 安価に SSAI の配信が可能に
- プレイヤーを作り込めば CSAI 相当の広告視聴ログが取得できる
- AD の知識やエンコードの知識が必要なためハードル高い
- 広告素材はエンコードのパラメータに注意
- CSAI と SSAI の違い
  - どちらを採用するかは予算とやりたい事による
今後
- MediaLive 使って行きたい
- MediaTailor がプレロールに対応したので使っていきたい
- VOD での運用
- MPEG-Dash の配信

事例紹介２北海道テレビ株式会社三浦さま

最後は最近各所で発表をされています三浦様による有料ライブ配信サービスを実施したお話です。

InterBEE2019のレポートもありますのでこちらもご覧ください。

[レポート] Inter BEE 2019で聞いてきた「メディア業界におけるクラウド活用最新事例」（その 1） #interbee2019

有料ライブ配信サービスを始めたきっかけ
- 視聴データの分析に手をつけようとした
  - いろんな課題が存在している
- そこで課金サービスに目をつけた
- 稼ぐ技術にフォーカス
有料ライブ配信サービスの要件
- アーカイブなしの有料ライブ配信
- テレビと同等の物を求められた
開発体制
- 3名
- プロマネ、プログラマ2名
- コンサルなどはクラスメソッドに依頼
構成
- SPA
  - Nuxt.js を採用
- 初めて CI/CD, Git を使った
- SaaS を積極採用
  - やらないことを増やしたい
  - Stripe
  - Auth0
- MediaServices
- DRM
- 各サービス間は API でやりとり
- iOS 見れない問題に対応するための仕組みも検討
- 買ったけど見れない場合の対応も準備しておいた
結果
- 黒字！
- 社内で局長賞というものをもらった
勉強方法
- EC2 も DB もわからない
- ゴールを実現するために本当に必要な物を使用する
- 難しそう？
  - 放送技術者はもっと難しいことをやっているはず
- 放送と通信の融合は放送技術者の熱量によってのみ実現される！